BBS Toolkit/BBS Toolkit.iso/remote/rur_251.zip/RUR.DOC

Text File | 1991-09-08 | 14KB | 328 lines

                             R U R  v 2.51


                      The RemoteAccess Users Ratio System

                                by Ron Huiskes

                       Copyright (C) InterSoft 1990-1991
                              All Rights Reserved






╓─────────────────────────────────────────────────────────────────────────────╖
║ ░░░░░░░ What exactly is RUR ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║
╙─────────────────────────────────────────────────────────────────────────────╜


  Ever been irritated that some users only downloaded, and downloaded and..?

  Well, Here is RUR...

  RUR is a complete Up/Download Ratio System. It will take full control over
  your users and their ratio. It will downgrade a users level if their ratio
  is too high,  and it will upgrade their level if they uploaded enough, and
  their ratio is okay again...

  Until here there is nothing special, you would say....  There are a lot of
  utilities that do it this way, but RUR goes futher...

  When RUR downgrades a users level,  it sends  a message to the person tel-
  ling him so, using the RA message base, specifying exactly how much he has
  to upload to be reased back...  (e.g when upgrading RUR sends a thanks for
  uploading message)

  And, if a users level gets downgraded and the user logs on, and he decides
  to upload some files  to get his ratio back up,  he doesn't  have to  wait
  until the next event,  where RUR will upgrade him. No, He simple pops into
  a little door  ( supplied with RUR ) and that door will online upgrade his
  level... (if his ratio is okay after the upload offcourse)

  Also,  RUR  will make a  complete loglist  of all the changes made in your
  users.bbs, so you can control everything RUR does...

  And, users can see completely HOW their ratio is been calculated. They en-
  ter the RUR_DOOR and get the complete picture...


╓─────────────────────────────────────────────────────────────────────────────╖
║ ░░░░░░░ Features of RUR ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║
╙─────────────────────────────────────────────────────────────────────────────╜


  ■ Specially written for the RemoteAccess BBS v1.0.

  ■ Easy to setup.

  ■ Easy implementation in RA, using SECxxx.A* files and limits.ctl.

  ■ RUR can make a specific logfile containing every calculation.

  ■ Sysop can specify a free amount of Kilobytes the user may
    download before RUR takes action

  ■ Special RUR Door which lets your users exactly see how their ratio
    is being calculated.

  ■ RUR can send messages to the user when his level is up or downgraded,
    containing many different control codes.

  ■ And much more...


╓─────────────────────────────────────────────────────────────────────────────╖
║ ░░░░░░░ Support ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║
╙─────────────────────────────────────────────────────────────────────────────╜


  I've choosen to make RUR support  only Kilobytes  instead  also Numbers of
  files. I don't think it's a good idea to work with numbers of files.   For
  example: If a user downloaded 10 files of 100 K, with a ratio of  1:10  he
  can upload 1 file of 1 K in order to get his ratio okay.  So, because that
  system doesn't work right, RUR will only count Kilobytes...

  And, RUR works with levels not with flags...
  Levels  are much  easier to use,   you can specify different kind of daily
  download limits depending on levels, timelimits etc...

  For every  level you have ( called the 'good level' ) and  want to let RUR
  take action on, you must make another level (called the 'bad level').
  Every  time a users ratio is not  correct, it will be lowered to the  'bad
  level'  by RUR.  Offcourse, the user will be upgraded by  RUR to the 'good
  level' if his ratio is correct again.

  If you understand this, you can see why I made  RUR  follow the above con-
  cept. If you have 2 different levels for the same users group (e.g. 99 and
  100)  it is so much easier to keep control of the limits.  You now can de-
  lare in your limits.ctl file that people with level 99  are not allowed to
  download (or just a tiny little bit).  You can  for example make a special
  sec99.a* file (see the RA docs) in which you tell them why you are using a
  ratiosystem... Well, to make a long story short, a ratiosystem with levels
  is much easier for everyone instead of a ratiosystem with flags.

  RUR is specially written for  RemoteAccess,  it will not work on  Quickbbs
  systems, because it uses specific RA control files.

╓─────────────────────────────────────────────────────────────────────────────╖
║ ░░░░░░░ Installing RUR ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║
╙─────────────────────────────────────────────────────────────────────────────╜


  RUR are three programs:

  RUR_PRG.EXE, which you have to run on a daily bases (in your nightly event
               for example)  which globally checks all users and up or down-
               grade their level.
  RUR_DOOR.EXE is the RemoteAccess Door,  which users can use when they have
               uploaded enough,  and they don't want to wait  until the next
               event to get their level raised back.
  RUR_FD.EXE   which comes in handy if you run Filedoor on your bbs. See the
               special RUR_FD.DOC for more details.


  You have to make a control file for both programs in order to run correct-
  ly. Both programs use the SAME control file, called RUR.CTL.

  The format of the RUR.CTL file is very simple:

    First line:
                  Free download in kilobytes.
    Second line:
                  Example Ratio for RUR_DOOR
    Third (and following) lines:
                  <low security> <normal security> <ratio> [msgfile]

  On the first line  you must supply  a number of Kilobytes  which new users
  can  download for free,  before any  ratio checking is done. If you do not
  want to give free downloads in the beginning, set this field to 1.

  The second line will only be used in RUR_DOOR,  e.g. it will be used as an
  example for users  for who you don't setup a ratio  ( special friends, co-
  sysop) but who accidently enter the door.     Even if your special friends
  ratio with this number isn't correct, RUR will not lower him.

  The third (and optionally following lines) is the important thing. On this
  line you supply the level who WILL be effected by RUR.  For example,  your
  level for normal users is 100.   You must now make a special level for RUR
  to use when RUR downgrades a user. (for example level 99).

  The third line could look like this:

  99 100 5
  │   │  │
  │   │  └ The 5 means ratio 1:5.  Users must upload 100 K for every 500 K
  │   │    they downloaded. (minus the number of free Kilobytes you supply
  │   │    on line 2).
  │   └─── The 100 stands for level 100. If a user has a korrekt ratio, it
  │        has this level.
  └─────── The 99 stands for level 99.  If a level 100 user doesn't have a
           a correct ratio, it will be downgraded to level 99 by RUR.

  If you have another group of users you can supply a fourth line, which has
  the same format as line 3 (and on, and on, you can supply up to 20 lines).

  Every level you  don't  mention in these lines will NOT be effected by RUR
  and will be left alone even if their ratio isn't correct.

  As a - fourth - parameter  you can use a  name for a file which contains a
  message text which RUR must  used in conjuction with the /M parameter. You
  must specify the name WITHOUT  extension. The extension of the filename is
  hardcoded into  '.DOW'  for messages  send to the bad level and  '.UP' for
  messages send to the good level.

  RUR_PRG and RUR_DOOR will look for the RUR.CTL file in the current dir, if
  it can't find it, it will search through your enviroment for the RA=<path>
  string  ( I believe every RA sysop has  this set, so that will no problem)
  and will look in that dir.
  If you have the  RA=<path>  set in your  enviroment, you can start RUR_PRG
  and RUR_DOOR from every directory you wish...


╓─────────────────────────────────────────────────────────────────────────────╖
║ ░░░░░░░ The RUR Door  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║
╙─────────────────────────────────────────────────────────────────────────────╜


  RUR_DOOR is a complete  DOOR for RemoteAccess. It doesn't need parameters,
  and it's easy to install. Just make a menutype 7 with in the optional data
  field "RUR_DOOR.EXE" ( without the quotes offcourse) and that's all !

  RUR_DOOR has complete fossil support and  smart carrier detect routines so
  you don't need a watchdog program or any other thing.
  RUR_DOOR  has also  DesqView support, and has most of the RA function keys
  build in!

  As long as  RUR_DOOR  can find the Dorinfo1.def and  Exitinfo.bbs files in
  the current dir, and the  RUR.CTL  file in your RA system directory every-
  thing works fine. In fact, you can try it out yourself, and  logon locally
  on your bbs and enter the door...

  RUR_DOOR.EXE will only upgrade a users level when his ratio is korrekt AND
  his level is defined in  RUR.CTL. Otherwise,  it only calculates a default
  ratio, and will show it to the user.

  RUR_DOOR cannot be used stand-alone. You have to run  RUR_PRG  every night
  to downgrade users, otherwise the door is completely needless.

  If you don't like the default colors RUR_DOOR has built in (only with ANSI
  enable) make a RUR_DOOR.CFG file with four lines: Define on every line the
  ANSI escape codes you'ld like, and RUR_DOOR will use these colors.
  I have enclosed a sample  RUR_DOOR.CFG  file, but if you  like the default
  colors, just delete this file.


╓─────────────────────────────────────────────────────────────────────────────╖
║ ░░░░░░░ Options and behavior ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║
╙─────────────────────────────────────────────────────────────────────────────╜


  RUR_PRG can use three parameters:

* RUR_PRG /M5    will instruct RUR_PRG to send a message in board 5 to every
  user who will be down or upgraded during  this run.  The  message will in-
  clude the calculation made by RUR_PRG.
  Boardnumbers 1 to 199 are valid.

  If you want to define your own message text, you have to create two files.
  As default they are called RUR_PRG.UP and  RUR_PRG.DOW but you can declare
  other names  in  RUR.CTL  on the  third  and  following  lines  as  fourth
  parameter. Any legal dos name (and path) will do...

  In these files you can explain why the user is up or downgraded.   You can
  use  several control codes starting with a '@' on the place where  RUR has
  to supply data. (see the control code section)
  RUR_PRG  has built in default message text, so if you don't want to change
  the  text  in the  messages, you  can delete  the example  RUR_PRG.DOW and
  RUR_PRG.UP which came in the archive.

  RUR does not check in which area it have to post the messages, so you bet-
  ter make sure  it's a local board. (Even better is to make a board comple-
  tely for RUR, so you can delete the recieved messages in your event)


* RUR_PRG /L   will instruct RUR_PRG to make a logfile, with all the changes
  made during this run.
  Everytime RUR starts, it will overwrite this logfile (if exist), so if you
  want to keep it longer than 1 day, copy it to another dir or rename it.

* RUR_PRG /S will turn off all screen writes. On some slow systems with  CGA
  cards, RUR would have run very slow. With this parameter supplied RUR will
  display almost nothing, and will speed up to 200% (on some systems).


  You can use the parameters  with each other, no particular order required.
  Up and lowcase are also treaded alike.


╓─────────────────────────────────────────────────────────────────────────────╖
║ ░░░░░░░ Control Codes  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║
╙─────────────────────────────────────────────────────────────────────────────╜


  The messages who RUR sends are totally configurable using control codes in
  the message  text.  These  control codes will be replaced by  RUR into the
  correct values.

  The following control codes are valid:

     @A    Users full name
     @B    Users first name
     @C    Users last name
     @D    Location
     @E    Last time user was on
     @F    Last date user was on
     @G    Number of Calls
     @H    Amount of files uploaded
     @I    Amount of kilobytes uploaded
     @J    Amount of files downloaded
     @K    Amount of kilobytes downloaded
     @L    Amount of kilobytes needed before level upgrade /
           Amount of kilobytes still available
     @M    Free K
     @N    Differents between free K and K downloaded
     @O    The effected Ratio (1:x)
     @P    Amout uploaded * ratio (in kilobytes)
     @Q    Amout the user has to upload in order to get upgraded
           (Use this only in rur_prg.dow, this number is actually @L div @O)
     @R    User's old level
     @S    User's new level


╓─────────────────────────────────────────────────────────────────────────────╖
║ ░░░░░░░ The last words : ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║
╙─────────────────────────────────────────────────────────────────────────────╜


  RUR is Cardware; Just send me a postcard of your city if you like the
  program:

                          Ron Huiskes / Interface
                               P.o. Box 528
                            2280 AM  Rijswijk
                                 Holland.

  If you have any comments on RUR, or you would like to contact me through
  Fidonet, call: [phone] / 3361381 or use [2:281/506.0]


  Disclaimer: The supplied program and all it's .Cfg file will only take up
              space on your harddisk, it  is suplied as-is. If it breaks in
              two, you own both halves...  It was fully tested on my system
              (running three lines on a  novell  network)  and nothing went
              wrong. But, I suggest that  you back-up  your  users.bbs file
              just in case every night before you run RUR.

<EOF>